Image  Cover  Sheet 


SYSTEM  NUMBER 

TITLE 

A  DYNAMIC  PROGRAMMING  CONCEPT  FOR  STRATEGIC  PLANNING 


System  Number 
Patron  Number 
Requester: 


Notes: 


DSIS  Use  only 


CLASSIFICATION 

UNCLASSIFIED 


Deliver  to 


DEPARTMENT  OF  NATIONAL  DEFENCE 

CANADA 


OPERATIONAL  RESEARCH  DIVISION 
DIRECTORATE  OF  OPERATIONAL  RESEARCH  (JOINT  &  LAND) 
DOR(J&L)  RESEARCH  NOTE  RN  9819 


A  DYNAMIC  PROGRAMMING  CONCEPT  FOR  STRATEGIC  PLANNING 

BY 

Mr.  S.  Isbrandt 
NOVEMBER  1998 


OTTAWA,  CANADA 


M  National  Defense 
Defence  nationale 


OPERATIONAL  RESEARCH  DIVISION 
CATEGORIES  OF  PUBLICATION 


ORD  Reports  are  the  most  authoritative  and  most  carefully  considered 
publications  of  the  DGOR  scientific  community.  They  normally  embody  the  results 
of  major  research  activities  or  are  significant  works  of  lasting  value  or  provide  a 
comprehensive  view  on  major  defence  research  initiatives.  ORD  Reports  are 
approved  personally  by  DGOR,  and  are  subject  to  peer  review. 

ORD  Project  Reports  record  the  analysis  and  results  of  studies  conducted  for 
specific  sponsors.  This  Category  is  the  main  vehicle  to  report  completed  research  to 
the  sponsors  and  may  also  describe  a  significant  milestone  in  ongoing  work.  They 
are  approved  by  DGOR  and  are  subject  to  peer  review.  They  are  released  initially 
to  sponsors  and  may,  with  sponsor  approval,  be  released  to  other  agencies  having  an 
interest  in  the  material. 

Directorate  Research  Notes  are  issued  by  directorates.  They  are  intended  to 
outline,  develop  or  document  proposals,  ideas,  analysis  or  models  which  do  not 
warrant  more  formal  publication.  They  may  record  development  work  done  in 
support  of  sponsored  projects  which  could  be  applied  elsewhere  in  the  future.  As 
such  they  help  serve  as  the  corporate  scientific  memory  of  the  directorates. 

ORD  Journal  Reprints  provide  readily  available  copies  of  articles  published 
with  DGOR  approval,  by  OR  researchers  in  learned  journals,  open  technical 
publications,  proceedings,  etc. 

ORD  Contractor  Reports  document  research  done  under  contract  of  DGOR 
agencies  by  industrial  concerns,  universities,  consultants,  other  government 
departments  or  agencies,  etc.  The  scientific  content  is  the  responsibility  of  the 
originator  but  has  been  reviewed  by  the  scientific  authority  for  the  contract  and 
approved  for  release  by  DGOR. 


DEPARTMENT  OF  NATIONAL  DEFENCE 


CANADA 


OPERATIONAL  RESEARCH  DIVISION 
DIRECTORATE  OF  OPERATIONAL  RESEARCH  (JOINT  &  LAND) 


DOR(J&L)  RESEARCH  NOTE  RN  9819 


A  DYNAMIC  PROGRAMMING  CONCEPT  FOR 
STRATEGIC  PLANNING 


by 


Mr.  S.  Isbrandt 


Directorate  Research  Notes  are  written  to  document  material  which  does 
not  warrant  or  require  more  formal  publication.  The  contents  do  not 
necessarily  reflect  the  view  of  ORD  or  the  Canadian  Department  of 
National  Defence. 


OTTAWA,  ONTARIO 


NOVEMBER  1998 


ABSTRACT 


This  concept  paper  explores  how  a  Dynamic  Programming 
methodology  can  contribute  to  a  defence-oriented  strategic 
planning  analysis.  A  sample  problem  is  described  and  solved  using 
Dynamic  Programming.  Advantages  and  disadvantages  of  the 
methodology  are  presented.  Implementation  details  and  software 
code  are  included  in  an  Annex. 


RESUME 

Ce  rapport  conceptuel  indique  comment  la  m£thodologie  de 
programmation  dynamique  peut  contribuer  h  une  analyse  de 
planification  strategique  pour  la  defense.  On  ddcrit  un  probleme 
comme  exemple  et  il  est  resolut  avec  la  programmation  dynamique. 
Les  benefices  et  desavantages  de  la  methode  sont  presentes.  Les 
details  de  la  mise  en  oeuvre  du  logiciel  sont  inclus  dans  une  annexe. 


EXECUTIVE  SUMMARY 


In  this  note,  long-term  strategic  planning  is  viewed  as  being  intrinsically  related  to 
Canadian  Forces  capabilities.  The  driving  force  is  to  plan  for  a  capability  mix  which  best 
suits  Canadian  Forces  requirements,  and  to  let  the  desired  capability  mix  in  turn  drive 
acquisition  and  maintenance  programs.  A  methodology  that  supports  such  long-term 
planning  would  not  replace  work  already  done  in  the  individual  environments,  but  would 
provide  an  integrating  overview  of  the  total  forces. 

One  of  the  methodologies  that  might  be  suitable  for  long-term  strategic  planning  is 
Dynamic  Programming.  A  small  sample  problem  using  three  capabilities  is  described, 
and  an  implementation  of  the  method  is  illustrated  for  the  problem. 

A  short  assessment  of  the  Dynamic  Programming  method  is  presented.  In  theory,  it  is  a 
method  applicable  to  strategic  planning.  In  practice,  the  usefulness  of  the  methodology 
depends  on  whether  it  is  possible  and  practical  to  bring  together  the  types  of  input  data 
which  best  suit  the  capabilities  of  the  method. 

In  an  annex,  considerable  detail  is  presented  for  both  a  software  implementation  of 
Dynamic  Programming,  and  the  solution  of  the  sample  problem. 
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Introduction 

promise  forhelpfri^to  ^nrd^SC(Ste.™om™, r^°f0,0^S  ““  h°‘d 
purpose  of  this  note  is  to  present  one  strategic  planning.  The 

that  may  be  considered  for  this  purpose  or  that  mavh  1118  jf  °ne  of  several  Possibilities 
methodologies  in  a  suite  of  tools  used  to  addre^Q  7 1  6  -USed  t0  comPlement  other 
Although  the  current  work  involving  Scenari  •  ^S1S -supporting  strategic  planning. 

frame  of  5  to  20  yearsT*e  the  mXl  1  ‘°  eVentUa,ly  address  a  toe- 

time-frame,  if  needed.  ’  °  °gy  Presented  here  can  address  a  longer 


The  Strategic  Planning  Problem 

stategi™Sg ^Sssd°RXCsomf ' ' ^  of  He  long-term 

look  a.Iong-tenn\USp^SOmsgXrmo?0terif CS  ”  for  a  ““nee™’ 

and  discussed  over  time  on  the  way  to  develoZt?  <=ons, derations  to  be  defined 

methodology.  P  ug  a  more  mature  and  realistic 

as  behr^SSSSd ££*£,' °f  = Defe”“  *  viewed 
for  a  capability  mix  which  best  s^Sa*™ ^  dri™S  foree  is  to  P>“> 
capability  mix  in  turn  drive  the  programs  which  arm  reqm5ements’  and  to  let  the  desired 
facilities,  personnel,  and  so  on.  nftoe  Irf„d  o?  !  ^  mamtain  equipment, 
from  5  years  in  the  future  up  to  20  or  momyemt  tat^eST  ^  b“ iS  566,1  to  be 

set  of  eleven  scenario”  which  arc  represmtatiwof13’’™"^  p™cessare  “  turn  related  to  a 
and  operations.  These  scenarios  have  been  dev  r  fp?sslb,  e  Canadian  Forces  missions 
the  department,  for  use  in  planning  within  DNDfRef  n‘ g”  with  ?“idance  from 

mixes  to  projected  performance  in  the  1  \  By  relatmg  possible  capability 

capabilities,  in  order  to  hdp“«e^fne ‘Se  ••  nan°S’  ‘1  *  P°5Sib,e  to  “rate”  the 
the  forces.  "erp  determ, ne  better  as  opposed  to  “worse”  capability  mix  for 

that  wo^b^S^SSn  JheSttoe*?odrceT  “  “  ^^on  of  analysis 

The  environments  afready^Tou, ^  maritime'  “d  air), 
expected  that  this  methodol^would  mv  to  rentee  own  Particular  perspectives.  It  is  not 
environments  rather  it  t«  •  6place  Work  already  done  by  the 

help  in  investigating  trade-offs  wherJthmmav be  °VCrvieW  ofthe  totaI  forces-  This  will 
between  capabilities  that  might  be  provided  bv  diff  lnc°nsistencies  or  duplication 
provide  understanding  as  to  how  the  canabilitL  5^?  ®n™nments-  will  also  help 
might  best  work  together  in  a  **  e™r“ 
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The  Dynamic  Programming  Methodology  ^  strategic 

6  One  of  the  potential  methodologies  be“>Sc°”  q  technique  could  be  used  to 
planning  problem  is  Dynamic  option  consists  of  a  series 

investigate  long-term  plmm®  °F >  •  over  a  sequcIlce  of  time  periods  (nominally 

Some  of  its  desirable  .  large  nranber  of 

b.  G™n fte  right  characteristics  for  a  “g^TSnot 

can  determine  an  optimal  ^ “  "d  to  he4tic). 

necessarily  optimal  answer  (optmuzer  as  oppose  Hifferences 

set  UP  to  either  optimize  for r  a itanW>  t(0  ®ptimi  J  throughout  a  time  period  (e.g. 

SSSKCSl.*"-"-  . 

s.  "srcssKSssaus-  w— *  „ 

Capabilities  and  “costs”  of  moving  from  one  capability  level  to  another, 
b.  objectives  for  the  analysis,  used  to  determine  how  good  or  bad  one  possi  e 
oDtion  is  compared  to  others,  and 

C.  cltiaintswhichdetermhieboundswitiiin which 

9  Although  the  Dynamic  ProgramnimE  metlMcl  bas  a  num  &  number  of 

characteristics,  the  long-term  strategic  P1™ ”|  ^“^would  be  required  to  obtain 
analysis  inputs.  This  in  turn  m^n“s"oS^r  to  implement  the  method.  As 
and  verify  suitable  ratings,  consttaints,  ^  ^  good>  "believable”  inputs  m 

with  all  methods  being  considered,  it  ‘  meaningful  results, 

order  to  be  able  to  provide  a  quality  analysis  with  m  S  ^  m  Wtial 

10.  The  Dynamic  Programming ;  ^Xffie^f  the  Canadian  Forces  today.  All 

state,  which  would  correspond  to  s  y,  th  j1  capability  options  in  the  first  stage 

possible  transitions  from  the  initial  stage 
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are  enumerated  and  recorded.  The  effectiveness  or  desirability  of  each  of  the  options 
reached  in  the  first  stage  is  rated  against  some  pre-defined  objective.  Any  constraints 
(cost  or  otherwise)  which  restrict  the  capability  options  allowed  are  taken  into  account. 

1 1 .  Then,  all  possible  transitions  from  the  first  stage  to  the  second  stage  are 
enumerated,  recorded,  and  rated.  Each  of  the  feasible  options  that  can  be  reached  in  the 
second  stage  retains  a  “memory”  of  the  option  which  preceded  it  in  the  first  stage. 

12.  The  methodology  repeats  this  process  throughout  the  time  period  of  analysis.  All 
transitions  from  options  at  one  stage  to  the  next  stage  are  examined,  each  of  the  resulting 
options  is  rated,  and  a  “memory”  of  how  best  to  reach  each  possibility  is  retained.  Again, 
constraints  are  allowed  for  as  necessary. 

13.  Eventually  the  last  stage  is  reached,  an  option  that  is  rated  highest  according  to 
the  pre-defined  objective  is  identified,  and  the  intermediate  options  can  be  identified  to 
show  how  a  progression  can  be  made  from  the  initial  option  to  be  desired  last  option. 


The  Sample  Problem 

14.  For  the  purpose  of  this  note,  a  very  simplified  smaller  problem,  but  with 
characteristics  typical  of  the  larger  strategic  planning  problem,  will  be  used  to  illustrate 
the  dynamic  programming  methodology. 

15.  The  sample  problem  used  to  illustrate  the  Dynamic  Programming  methodology  is 
nominally  based  on  a  simple  “collective  defence”  scenario,  with  only  three  defined 
capabilities.  An  initial  capability  level  is  specified  for  a  base  time  0,  and  possible 
capability  options  are  analyzed  over  5  subsequent  time  periods. 

1 6.  The  three  capabilities  are: 

a.  Medical  Support, 

b.  Lift  and  Position,  and 

c.  Command  &  Control  (Joint  Force  Headquarters) 

1 7.  Transition  costs,  for  maintaining  capabilities  at  certain  levels,  or  for  changing 
capability  levels  from  one  time  period  to  another  are  defined  as  inputs  to  the 
methodology.  Constraints  such  as  costs  or  threshold  performance  measures  are  defined 
and  incorporated  into  the  methodology  as  well. 

18.  An  “objective”  measure  is  also  required  in  order  to  determine  the  desirability  of 
any  mix  of  capabilities.  This  allows  the  identification  of  “better”  or  “worse”  capability 
mix  options  over  time,  from  the  initial  base  time  to  the  end  of  the  last  time  period. 

Possible  Solution  Methodology  Oriented  to  Dynamic 
Programming 

Dynamic  Programming  Characteristics  for  the  Sample  Problem 

1 9.  The  sample  problem  represents  a  planning  process  starting  with  an  initial  stage  0 
and  progressing  through  subsequent  stages  until  stage  5. 
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20.  The  transition  costs  for  a  change  in  any  capability  level  are  shown  in  Table  1 . 


Table  I  -  Capability  Transition  Costs 


21 .  For  simplicity  in  the  sample  problem,  it  is  assumed  that  the  transition  costs  for  a 
change  in  any  capability  level  are  constant  over  the  time  period  of  the  analysis.  The 
methodology  can  be  made  more  realistic  by  incorporating  a  time  dimension  and  defining 
transition  costs  for  each  individual  time  period. 

22.  Again,  for  simplicity  in  the  sample  problem,  the  “total”  transition  cost  from  one 
capability  mix  at  one  stage,  to  another  capability  mix  at  the  next  stage,  is  simply  the  sum 
of  the  individual  capability  transition  costs.  A  more  realistic  approach,  which  can  be 
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incorporated  within  the  methodology,  is  to  cost  the  transition  of  moving  from  one  vector 
of  capabilities,  to  another  vector  of  capabilities  (which  may  be  different  from  the  sum  of 
the  individual  capability  transition  costs),  taking  the  time  dimension  into  account.  The 
overall  logic  of  the  methodology  remains  the  same,  but  it  necessitates  that  more 
complicated  data  structures  must  be  accommodated  in  any  program  code. 

23.  Constraints  can  be  included  in  the  dynamic  programming  process.  As  option 
transitions  from  one  stage  to  another  stage  are  investigated,  any  applicable  constraints  are 
taken  into  account.  This  may  potentially  flag  an  option  as  infeasible.  In  the  sample 
program,  one  constraint  applied  is  that  the  total  cost  of  capability  transitions  in  moving 
through  the  time  periods  cannot  exceed  ten  times  the  number  of  periods.  So,  for 
example,  at  the  end  of  the  fifth  period,  the  total  cumulative  cost  cannot  exceed  10*5  = 
50.  This  particular  constraint  has  the  effect  of  alio  wing  “banking”  of  resources.  For 
instance,  one  feasible  solution  may  involve  a  cost  of  8  going  to  stage  1,  and  a  cost  of  12 
going  to  stage  2.  Although  one  of  the  period  costs  is  in  excess  of  the  average  allowed  per 
year,  the  cumulative  cost  is  still  within  the  overall  constraint.  All  transitions  will  have  to 
be  consistent  with  this  cumulative  cost  constraint. 


24.  Another  constraint  applied  is  that  any  capability  mix  allowed  as  a  feasible  option 
must  meet  at  least  a  certain  threshold  of  performance  capability.  The  intent  of  this  is  to 
ensure  that  during  the  analysis  no  particular  capability  mix  at  one  time  period  will  be 

sacrificed  to  low  performance  levels,  in  order  to  “up”  the  other  capability  mixes  in  the 
other  time  periods  for  a  higher  average  capability. 

25.  Enforcing  constraints  such  as  the  ones  described  above  simply  reduce  the 
solution  space  to  be  examined  by  the  methodology,  by  screening  out  options  which 

would  not  be  allowed  as  a  final  solution  in  any  case. 

26.  A  Dynamic  Programming  analysis  requires  an  objective  in  order  to  judge  which 
capability  mix  options  are  preferable  to  others.  Possible  objectives  could  be  based  on 
paradigms  such  as: 


a.  One  encompassing  measure  of  effectiveness  of  the  sets  of  capability  mixes  over 
the  time  periods. 


b.  Some  overall  confidence  or  reliability  measure  that  any  significant  defence 
requirement  will  be  adressed  throughout  the  time  period  of  analysis. 

c.  The  objective  could  be  based  on  the  average  measure  of  capability  mixes  over  all 
periods,  or  by  maximizing  the  objective  at  only  the  end  period,  and  so  on. 

27 .  The  obj  ecti ve  measure  that  is  best  to  use  for  the  purpose  of  analysis  will  depend 
on  what  are  the  important  driving  factors  encompassing  the  strategic  planning  process. 

28.  For  the  sample  problem,  a  simple  “reliability  measure”  was  used  as  the  objective 
measure  for  illustrative  purposes  only.  At  any  given  stage,  a  reliability  term  is  calculated 
as: 


(0.9999-  (  (3-CAP1)  /12) )  *  (0.9999-(  (  3-CAP2  )/6) )  *  (0.9999-(  ( 3-CAP3  )/12) ) 

where  CAP1  corresponds  to  the  Medical  Support  capability  level,  CAP2  corresponds  to 
Lift  &  Position,  and  CAP3  corresponds  to  Command  &  Control,  (JFHQ). 
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29.  Note  that  when  capability  levels  are  high  at  3,  nothing  will  be  subtracted  from  the 
O.9999  term  paired  with  the  capability,  and  the  individual  capability  level  will  not  reduce 
the  overall  measure  of  reliability.  On  the  other  hand,  as  capabilities  are  rated  at  lower 
levels,  they  will  impact  the  overall  product  measure.  The  overall  reliability  will  be  more 
sensitive  to  the  CAP2  term,  (since  it  is  divided  by  6  rather  than  by  12)  -  so,  lower  values 
of  CAP2  will  reduce  overall  reliability  more  than  equivalent  lower  values  of  either  CAP1 
or  CAP3.  This  reflects  an  assumption  in  the  problem  that  CAP2  is  more  critical  to 
overall  reliability,  and  that  CAP1  and  CAP3  have  lesser  but  equal  impacts. 

30.  The  overall  objective  measure  is  applied  over  all  the  stages-  in  this  case  we  use 
as  a  measure  the  average  reliability  up  to  and  including  the  stage  being  examined, 
resulting  in  an  overall  average  when  the  final  stage  is  completed.  So,  the  intent  of  the 
example  is  to  find  the  set  of  options  over  all  stages  that  maximizes  the  average  reliability 
of  the  capability  mix  over  the  given  time  period. 

Dynamic  Programming  Algorithm  Concept 

31.  As  mentioned  before,  the  Dynamic  Programming  methodology  begins  at  an  initial 
state.  All  possible  transitions  from  the  initial  stage  to  allowed  options  in  the  first  stage 
are  enumerated  and  recorded.  The  effectiveness  of  each  option  is  rated  against  an 
objective.  Any  constraints  that  restrict  the  capability  options  are  considered. 

32.  Then,  all  possible  transitions  from  the  first  stage  to  the  second  stage  are 
enumerated,  recorded,  and  rated.  What  this  means,  in  more  detail,  is  that  every  option  in 
the  second  stage  is  considered,  one  by  one.  All  possible  transitions  from  feasible  options 
in  the  first  stage  to  a  particular  second  stage  option  are  examined,  and  any  transition  is 
discarded  from  the  process  if  it  violates  problem  constraints.  Of  those  transitions  that 
remain  (if  any)  the  one  associated  with  the  best  objective  value  is  chosen  as  the  preferred 
route  to  reach  that  particular  second  stage  option.  (If  no  feasible  transition  exists  to  a 
second  stage  option,  it  is  discarded  from  any  possible  solution.)  After  looking  at  all  the 
second  stage  options,  each  of  them  that  can  be  reached  by  a  feasible  transition  retains  a 
“memory”  of  its  best  predecessor  (i.e.  the  stage  one  option  which  provides  its  best 
transition  path). 

33.  The  methodology  repeats  this  process.  All  transitions  from  options  at  one  stage  to 
the  next  stage  are  examined,  rated,  and  a  “memory”  of  how  best  to  reach  each  is  retained. 
Again,  constraints  are  allowed  for. 

34.  Eventually  the  last  stage  is  reached,  the  option  with  the  highest  rating  according  to 
the  objective  is  identified,  and  the  transition  path  can  be  identified  to  show  how  a 
progression  can  be  made  from  the  initial  option  to  be  desired  last  option. 

35.  This  process  is  illustrated  below  as  a  logic  diagram,  in  the  context  of  time  periods 
expressed  as  years: 


Figure  1  -  Dynamic  Programming  Logic 
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hS.^^Detail^offo^^ution  procedure  for  t^e.s^^^^^™t^yel?eSC”':)e^  ^ 

Annex.  The  generated  solution  is  summanzed  m  the  following  ta  . 


Stage  ["Option 


Medical 

Support 


Table  II  -  Generated  Solution 

Predecessor 


Lift  & 
Position 


C&C 

(JFHQ) 


Cumulative 
Cost 


Average 

Reliability 


37  The  starting  position  for  the  sample  problem  is  one  unit  of  each  capabili^ 

0  ThisnSito  Preferred  to  as  option  1,  and  is  represented  by  a vector  [1, 1, 1].  'vhteh 

corresponds  to  the  levels  for  Medical  Suport ^  “  1  2]),  option  3  (as  [1 , 1 , 

so  on  "pS°27  (- R  M  For  the  sample  analysis,  all  27  options  are 

^""Tfeasible  nansitio^  from  thymtial  .age  <*«onfl,  1. 

1.  The  ^resulting *  f??f  *  ^To^y’atie  sar^e  eap^lity  level  of  [1, 1.  U  a 

options  2, 10, 11,  and  19).  If  on  where  the  reliability  at  any  stage 

threshold  reliability  constra.nl .applied  in  *o  exampte.  where  me  r^  m 

must  not  fall  below  0.5,  would  be  violated.  The ’  *{  “  stage.  For  example,  a 

excluded  because  they  exceed 3  ^tten  txamining  the  cost  Table  I  results  in  a  cost  of 
:^50=“  ^  wldcMs^nsiderably  in  excess  of  die  allowed  cost. 

39.  Continuing  from  stage  1 ,  all  of  die  transitions  threshold^ 

one  of  the  four  feasible  options  as  a ' eS  out"  non-allowed  transitions,  and 
constraints  and  cost  constraints  ™  *  *  more  ^  one 

^edece^or^^^redec^o^wlhch  confutes  to  the  larger  objective  value  is  retained. 

40  Stage  by  stage,  the  process  continues  until  the  options  at  the  final  stage  have  been 
Cached If S  /detailed  representadon  is  shown  in  dte  Annex.) 

41  The  “best”  option  mix  having  the  maximum  aven aSe,rfb °Tvrith a 

eacassjsgsSSSSSar 

backtracking  through  the  predecessor  chain,  a  complete  picture  ox  tn  p 

mixes  over  all  five  dme  periods  can  be  determined. 


r 
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Assessment  /  Conclusion 

f?ni1p nZhefDy+namiC  Pr°grammin8  methodology  is  a  powerful  technique  for  generating  a 
I  tf°P  11  decisions  over  time,  providing  the  problem  to  be  aLyzedcan  be  § 
stated  m  terms  required  by  the  methodology.  Based  on  the  concept  trial  described  here 

e  m“gy  l0°kS  Pr0mismg  enough  to  warrant  a  further  trial  on  a  larger  problem  ’ 
problem  18  ^  m°re  C°mpleX  in  ^  natUfe  °f  a  realistic  stmtegic  planning  ’ 

capabilities, Tuch^^08^  *  ***  am°“‘  of  toP“  related  “  operational 

"  fr°m  °”e  o^on  *o  another 

r“dnnlali:iS!ti0nal  ^  ^  ^  “  be  “nsidered  over 

c.  identification  of  cost  and  performance  constraints  which  limit  the  feasible  ontinns 
which  can  be  considered  at  different  time  periods,  and  °P“0ns 

£por^“^^^  he  an 

ork  done  on  Hierarchial  Analysis  Frameworks  (Ref.  3).  ’ 

p  Also,  the  results  of  the  methodology  might  in  turn  be  used  by  another  analysis 
Porinstance,  candidate  solutions  from  Dynamic  Programming  analyses  using 

“ ssr  ae  CEPS  (Capifa'  E^“ 

terms  of  an  actual  acquisition  ptan  differences  m  impact  between  them  in 
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ANNEX  A  -Sample  Program  Description 


A-  1 


•  *  Analyze : 


•  *V  V; 


^Repwts 


^dfPTroCCapabiMis  Planner. 


Figure  A  -  1  Main  User  Screen 


Upon  choosing  the  “View  /  Change  Analysis  Inputs”  button,  the  user  is  first  informed 
that  they  will  have  to  specify  a  folder  location  where  database  files  for  the  scenario  to 

analyze  can  be  found, 


The  program  described  here  was  developed  using  Delphi,  as  a  prototype  concept 
illustration  of  how  the  Dynamic  Programming  methodology  could  be  implemented. 
(Further  software  details  are  included  later  in  the  Annex.)  When  the  application  is 
started,  the  user  is  met  with  the  following  screen: 


User  Guide  to  the  Sample  Program 


A  -  2 


Figure  A  -  2  Select  Input  Location  Prompt 


and  then  they  are  prompted  to  actually  specify  the  folder  with  an  Open  Dialog. 


The  program  proceeds  to  display  basic  input  information  contained 
database  inputs,  as  shown  in  Figure  A  -  4: 


in  the  scenario 


A  -  3 


Figure  A  -  4  User  Input  Display/Edit 

In  Figure  A  -  4,  the  option  list  simply  enumerates  the  option  mixes  which t  are 40  be 

difficulty.  ,  .  , 

than  by  hard-wiring  the  objectives  into  program  code. 


A  -  4 


/•  fimChdits 


I  rt-f'-li, 


Presently,  the  cost  constraints  are  hard-wired  into  the  concept  program  code,  but  they 
also  could  be  set  into  a  format  where  they  would  be  set  at  run-time  instead. 

The  user  can  change  information  by  entering  changes  directly  on  the  form,  and  “posting” 
them  (hitting  the  curved  arrow  on  the  navigation  bar  below  the  appropriate  table)  to  the 
database.  The  form  can  be  closed,  to  return  to  the  main  screen. 

By  hitting  the  “Analyze”  button,  the  program  is  directed  to  carry  out  the  dynamic 
programming  algorithm  based  on  the  information  that  was  previously  displayed. 

By  depressing  the  “Results  Charts”  button,  a  new  screen  comes  up  which  displays  two 
choices,  one  for  overall  results  (“Show  Stages”)  and  one  for  the  best  allocation  of  options 
mixes  over  all  of  the  stages  (“Show  Max  Return”). 


A  -  5 


Figure  A  -  5  Feasible  Options  Chart 

(“Show  Stages”)  shows  all  feasible  (or  reachable,  given  model  constraints)  options 
throughout  the  five  stages  of  the  sample  problem. 

The  first  row  of  the  chart  has  only  four  values,  representing  the  only  four  option  mixes 
which  are  reachable  at  stage  one  from  the  initial  state  of  the  system.  The  second  row 
represents  the  option  mixes  which  are  feasible  at  the  second  stage,  and  which  are  also 
reachable  by  feasible  options  mixes  at  the  previous  stage.  The  third,  fourth,  and  fifth 
rows  continue  out  similarly.  The  height  of  the  bars  represents  the  “average  effectivenes; 
over  all  stages,  using  the  “best”  set  of  option  mixes  from  the  initial  state  through  to  the 
stage  represented  by  the  bar.  s 


The  toolbar  above  the  chart  can  be  use  for  numerous  functions  as  desired:  *  Series 
line  or  other  chart  style,  change  colours  of  chart  elements,  show  or  hide  the  chart  senes 

legend,  zoom  in  on  a  chart  detail,  and  so  on. 


Figure  A  -  6  Optimal  Option  Chart 

Figure  A  -  6  Optimal  Option  Chart  (“Show  Max  Return”)  shows  the  particular -sequence 
that  gives  the  best  answer  over  all  the  five  stages.  Double  clicking  on  the  bar  (as 
illustrated  above)  can  raise  a  balloon  prompt  showing  the  value  of  any  particular  b  . 

This  answer  corresponds  to  the  solution  shown  in  flie  main  paper,  and  diagrammatically 
illustrated  in  detail  elsewhere  in  this  Annex. 

From  the  main  application  screen,  the  user  can  also  activate  a  “Reports”  button.  This 
brings  forward  aform  as  shown  in  Figure  A  -  7  where  one  of  three  reports  can  be  chosen 

from  a  list.  The  report  can  be  displayed  by  activating  the  Show  Report  bu 


A  -  6 


Figure  A  -  7  Report  Selection  List 


A  -  7 


Figure  A  -  8  Report  Screen 

This  will  introduce  a  document  screen  similar  to  above,  where  the  relevant  report  can  be 
examined,  printed  out,  or  exported  to  a  disk  file  in  a  variety  of  formats. 


i 
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Detailed  Results  Diagrams  of  the  Sample  Analysis 


In  the  following  pages,  the  solution  process  carried  out  by  the  Dynamic  Programming 
application  on  the  sample  problem  is  shown  diagrammatically. 


Figure  A  -  9  shows  the  “solution  space”  available  initially,  and  within  the  five  time 
periods  or  stages.  Stage  0  shows  the  initial  state  with  a  capability  vector  [1,1,11  which 
represents  a  Level  1  for  the  Medical  Support  capability,  a  Level  1  for  the  Lift  &  Position 
capability,  and  a  Level  1  for  the  C&C  (JFHQ)  capability.  Stage  1  shows  27  capability 
option  vectors  ranging  from  [1,1,1]  (all  capabilities  at  lowest  level  considered)  to  [3  3 

3]  (all  capabilities  at  highest  level  considered).  The  other  stages  similarly  have  27  option 
vectors  shown.  F 

In  a  more  realistic  problem,  the  capability  option  vectors  considered  would  not 
necessarily  be  the  same  from  one  stage  to  another. 


T^gure  A  ~  1 0  represents  the  same  solution  space  of  capability  options,  but  represents 
them  as  a  senes  of  points.  So  Stages  1  through  5  have  a  point  corresponding  to  [1  1  1] 
at  the  bottom  of  a  column  of  27  points  representing  options  to  [3,  3,  3]  at  the  top.  ’ 


figure  A  -  1 1  illustrates  how  the  initial  “fan-out”  from  the  initial  capability  option  to 
those  options  at  Stage  1  which  are  feasible  -  they  are  within  cost  limits,  performance 
constraints,  and  basically  satisfy  all  restrictions  which  have  been  applied  as  part  of  the 
problem  setting. 


Figure  A -12  contmues  showing  the  continuing  chain  of  feasible  options  at  Stage  2 
which  are  reachable”  from  feasible  options  at  Stage  1 .  Where  an  option  at  Stage  2 

mi+h  lbC  reached  m°re  111311  one  route> the  Path  which  allows  the  option  to  be  reached 
with  the  greatest  objective  value  is  the  one  that  is  recorded.  (This  is  a  very  important  part 

of  the  Dynamic  Programming  methodology.)  Note  that  not  all  feasible  options  at  Stage  1 
have  a  way  of  continuing  on  to  Stage  2  within  the  problem  restrictions.  This  reflects  the 
case  where  an  option  at  Stage  1,  although  feasible  and  reachable,  does  not  make  sense 
because  there  are  no  possibilities  it  can  use  to  lead  to  a  feasible  Stage  2  option. 


EigHI^AjLi3,  Figure  A  -  14,  and  Figure  A -15  detail  the  forward  chaining  process, 
from  feasible  options  at  one  stage  to  feasible  options  at  the  next  stage,  up  to  Stage  5. 

Figure  A  -  16  highlights  with  a  star  the  one  feasible  option  at  Stage  5  which  has  the 
greatest  value  for  the  problem  objective  (option  vector  [3,  2,  2]. 


A  -  9 


Figure  A  -  17  illustrates  the  backtracking  process  from  the  best  option  at  Stage  5  to  the 
best  feasible  predecessor  option  at  Stage  4  (option  vector  [3, 2,  2]  again). 

w:„„_  A  .  i  s  Figure  A  -  1 9.  Figure  A  -  20,  and  Figure  A -21  show  the  complete 
backtracking  proSss  back  to  the  initial  option.  It  can  easily  been  seen  from  the  diagrams 
thatnone  ofthe  “top”  options  such  as  [3, 3,  3]  appear  as  feasible  options  since  they 

exceed  cost  limits.  Similarly,  none  ofthe  ’’lower’;  options  appear  on  the  best  ^smee 
they  are  superceded  by  other  superior  options  which  are  affordable,  and  provide  better 

objective  values. 

The  oath  shown  in  the  figures  corresponds  to  the  Table  II  solution  shown  in  the  main 
paper,  aid  the  BinnreA  -6  Optimal  Option  Chart  shown  in  the  application  User  Guide 

of  this  Annex. 


[3,3,3] 


[1,2,1] 

[1,1,3] 

[1,1,2]  [1,1,2]  - 
[1,1,1]  [1,1,1]  [1,1,1]  . 
Stage  0  1  2  3 


-  [3,3,3] 


-  U,l,2] 

-  H,l,l] 

4  5 


Figure  A  -  9:  Diagram  of  Capability  Vectors 


Stage 


Figure  A  - 10:  Capability  Vectors  Represented  as  Points 
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Figure  A  - 11:  Feasible  Stage  One  Options 


o 

0 

o 

o 

o 

0 

0 

0 

0 

o 

o 

0 

o 

o 

o 

o 

o 

o 

o 

o 

o 

o 

0 

o 

o 

o 

0 

4 


5 


OOOOOOOOOOOOOOOOOOOOOOOOOOO 


Stage 


Figure  A  - 12:  Stage  Two  Feasible  Options 
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Figure  A  - 14:  Stage  Four  Feasible  Options 
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Figure  A  - 15:  Stage  Five  Feasible  Options 
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Figure  A  - 16:  Stage  Five  Overall  Optimum 
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Figure  A  - 17:  Backtracking  to  Best  Option  at  Stage  Four 
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Figure  A  - 19:  Backtracking  to  Stage  Two  Best  Option 
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Software  Used  in  Developing  the  Sample  Program 

The  software  application  designed  to  illustrate  the  Dynamic  Programming  concept  was 
wded  using  Boriand  Delphi  3  Professional.  Delphi  is  available  from  Inpnse  (fomierly 
Borlrnd)  found  on  the  World  Wide  Web  at  http://www.inpnse.com/delphi/.  The 
application  runs  in  32-bit  Microsoft  Windows  applications.  The  application  als 
incorporates  the  use  of  some  add-on  developer  tools: 

.  Tonaz  6  5  for  Delphi  -  A  dBase  compatible  add-on.  It  allows  use  of  dBase  databases 

without  file  significant  extra  overhead  of  te  Borland 

with  Delphi.  Topaz  is  available  from  Software  Science  Inc.  Its 

http://softsci.com/ 

•  Crystal  Reports  6.0  Professional  -  a  reporting  utility  add-on.  Crystal  Reports ;  allows 
flexible  reporting  of  model  input  and  output  results  which  are  stored  in  databa 

format.  It  is  available  from  Seagate  Software.  Information  for  Crystal  Reports  can  be 
found  on  the  Web  at  http://www.seagatesoftware.com/ 

v Y  ^  0  32  Bit  -  The  full  Chart  FX3 .0  is  an  upgrade  to  the  version  provided 

Software  FX  This  tool  "exible^fton  of 
charts  to  help  portray  results  of  the  program  analysis.  Information  on  the  Web 
available  at:  http://www.softwarefe.com/ 

•  TParser  Version  10.1  -  a  Delphi  VCL  control.  TParser  (originally  written  by  Renate 
Schaaf  and  enhanced  by  Alin  Flakier  and  Stefan  HoftaeiSer)  is  avail abte  on  fte 
Internet  as  a  freeware  Delphi  control,  with  source  code.  This  control  is  used  in  the 
sample  program  to  allow  entry  of  mathematical  expressions  at  run-time,  parse  them, 
ZtZZZ  result.  Throws  greater  flexibility  for  the 

problem  characteristics  can  be  specified  after-the-fact  as  oppo  g 

wired”  into  the  compiled  program  code.  It  is  available  from  the  Delphi  Super  Page 
on  the  Web  at  http://sunsite.icm.edu.pl/delphi/  (use  the  DSP  search  engine  to  searc 

for  TParser  in  order  to  find  it). 

Delphi  source  code  for  the  *.pas  files  of  the  application,  as  well  as  pictures _of  the  form 

files  are  presented  in  another  section  within  the  Annex.  The  Delphi  form  fi 

themselves  (*.dfm),  Crystal  Reports  report  files 

tables  (*  dbf)  are  not  reproduced,  since  they  are  not  ASCII  based  forma  . 

parties  can  request  copies  of  these  files,  if  they  have  requirements  related  to  Defence 

Purposes. 
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Description  of  the  Program  Code 


The  Concept  Application  program  code  is  contained  in  a  number  of  Delphi  modules; 
some  of  which  are  also  associated  with  user-interface  forms. 

The  various  modules  or  units  are: 

•  charts,  with  form  frmCharts, 

•  DatModl,  with  form  DataModulel, 

•  input,  with  form  inputForm, 

•  main,  with  form  mainForm, 

•  option, 

•  report,  with  form  frmReport, 

•  spacing,  with  form  frmSpace. 
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Unit  charts  , 

This  unit  provides  a  form  and  code  for  representing  analysis  results  in  chart  form.  This  form  is  the  one  that  contains  the  ChartFX 

charting  control,  named  in  the  program  as  ChartFXl . 
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UNIT  CHARTS  CODE 


unit  charts; 

interface 

uses 

Windows,  Messages,  SysUtils,  Classes,  Graphics,  Controls,  Forms,  Dialogs, 
StdCtrls,  CfxVcl32,  ExtCtrls,  Buttons,  spacing; 
type 

TfrmCharts  =  class (TForm) 

Panel 1 :  TPanel ; 

Buttonl :  TButton ; 

Panel2:  TPanel; 

ChartFXl :  TChartFX; 

Button2 :  TButton ; 

BitBtnl:  TBitBtn; 
btnMaxReturn :  TButton ; 

procedure  ButtonlClick (Sender:  TObject); 

procedure  FormClose (Sender :  TObject;  var  Action:  TCloseAction) ; 

procedure  FormResize (Sender :  TObject); 

procedure  Button2Click (Sender :  TObject); 

procedure  btnMaxReturnClick (Sender:  TObject); 

procedure  FormCreate( Sender:  TObject); 

procedure  BitBtnlClick (Sender:  TObject); 
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private 


{  Private  declarations  } 
public 

{  Public  declarations  } 
end; 

var 

f rmCharts :  TfrmCharts ; 
showAverage :  boolean ; 

implementation 
{$R  *  .DEM} 
uses 

main,  input; 

procedure  TfrmCharts . ButtonlClick ( Sender:  TObject) ; 
var 

series,  point,  maxSoFar:  integer; 
begin 

if  inputForm. rgDisplay . Itemlndex  =  1 
then  showAverage  :=  true 
else  showAverage  :=  false; 

. maxSoFar  : =  0 ; 

{numberOf Options  :  =  27;  //Intended  to  generalize  later!  } 
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ChartFXl . Title [CHART_TOPTIT]  :=  'OBJECTIVE  VALUES  by  STAGE'; 

ChartFXl . Title [CHARTJBOTTOMTIT]  : =  ' Option  Number ' ; 

ChartFXl . Title [CHART_LEFTTIT  ]  :=  'Value'; 

ChartFXl .NSeries  ;=  numberOf Stages ; 

ChartFXl . NValues  :=  numberOf Options ; 

ChartFXl . OpenDataEx (  COD_VALUES,  numberOf Stages ,  numberOfOptions  ); 

for  series  :=  0  to  (numberOf Stages  -  1)  do 

begin 

ChartFXl . ThisSerie  ; =  series ; 

for  point  :=  0  to  (numberOfOptions  -  1)  do 

begin 

if  (stageOptions [  (series+1) ,  (point+1)  ]  <>  nil) 

then 

begin 

if  showAverage 

then  ChartFXl .Value [  point  ]  := 

(stageOptions [ (series+1) , (point+1) ] . CUM_EFF  ) / (series+1) 
else  ChartFXl . Value [  point  ]  := 

stageOptions [  (series+1),  (point+1)  ] ,CUM_EFF; 
if  ChartFXl. Value [point]  >  maxSoFar 

then  maxSoFar  :=  Round (ChartFXl. Value  [point] +1) ; 

end 

else  ChartFXl. Value [  point  ]  :=  CHART_HIDDEN; 
end; 
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end; 

ChartFXl . CloseData (  COD_VALUES) ; 
if  showAveraga 

then  ChartFXl . Adm [CSA_MAX]  :=  1.0 
else  ChartFXl. Adm [CSA_MAX]  :=  maxSoFar; 


for  series  :=  0  to  (numberOf Stages  -  1)  do 
begin 

ChartFXl . SerLeg [  series  ]  :  =  ’Stage  ' +IntToStr {  series  +  1); 

end; 

ChartFXl . Invalidate; 

ChartFXl. Visible  :=  True; 

end; 

procedure  TfrmCharts .FormClose (Sender:  TObject;  var  Action:  TCloseAction) ; 
begin 

ChartFXl. Visible  :=  False; 
end; 

procedure  TfrmCharts.FormResize( Sender:  TObject); 
begin 

ChartFXl. Top  :=  Panel2.Top  +  4; 
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CharfcFXl .Left  :=  Panel2.Left  +4; 

ChartFXl . Height  : =  Panel2 . Height  -  8 ; 

Char tFXl. Width  :=  Panel2. Width  -  8; 
end; 

procedure  Tf rmCharts . Button2Click (Sender:  TObject); 
begin 

f rmSpace . ShowModal ; 
end; 

procedure  Tf rmCharts .btnMaxReturnClick (Sender :  TObject); 
var 

index ,  index2 ,  series ,  point ,  maxSoFar :  integer ; 
bestOptionID,  bestPredecessorlD,  currentOption:  integer; 
delimiter:  string; 
maxRetum :  single ; 
begin 

if  inputForm.rgDisplay. Itemlndex  =  1 
then  showAverage  :=  true 
else  showAverage  :=  false; 

ChartFXl . Title [CHART_TOPTIT]  :=  'OPTIMAL  SELECTION  by  STAGE'; 
ChartFXl. Ti tie [CHART_BOTTOMTIT]  :=  'OptionNumber'; 

ChartFXl . Title [CHART_LEFTTIT  3  :=  'Value'; 


A  -  31 


ChartFXl . NSeries  :=  numberOf Stages ; 

ChartFXl . NValues  :=  numberOf Options ; 

{Zero  Out  Array) 

ChartFXl . OpenDataEx (  COD_VALUES,  numberOf Stages ,  numberOf Options  ); 

for  series  :=  0  to  (numberOf Stages  -  1)  do 

begin 

ChartFXl . ThisSerie  :=  series; 

for  point  :=  0  to  (numberOf Options  -  1)  do 

begin 

if  (stageOptions [  (series+1) ,  (point+1)  ]  <>  nil) 

then 

begin 

ChartFXl. Value!  point  ]  :=  0; 

end 

else  ChartFXl . Value [  point  ]  :=  CHART_HIDDEN; 

end; 
end; 

ChartFXl . CloseData (  COD_VALUES) ; 

ChartFXl . Adm [CSA_MAX]  :=  maxSoFar; 

for  series  :=  0  to  (numberOf Stages  -  1)  do 

begin 

ChartFXl . SerLeg [  series  ]  :=  'Stage  ' +IntToStr(  series  +  1  ); 
end; 
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maxReturn  : =  0 ; 

{Find  the  Max  Return  Value  in  the  last  stage,  and  corresponding  option} 

for  index  :=  1  to  numberOf Options  do 

begin 

if  stageOptions [  numberOf Stages ,  index  ] . CUM_EFF  >  maxReturn  then 
begin 

maxReturn  :=  stageOptions [  numberOf Stages ,  index  ] .CUMJEFF; 
bestOptionID  :=  index; 
end; 
end; 

ChartFXl . OpenDataEx (  COD_VALUES,  COD_UNCHANGE ,  COD_UNCHANGE) ; 

ChartFXl . ThisSerie  :=  (numberOf Stages  -  1) ; 
if  showAverage 

then  ChartFXl. Value [  bestOptionID  -  1]  := 

(stageOptions [  numberOf Stages ,  bestOptionID  ]. CUM_EFF) /numberOf Stages 
else  ChartFXl .Value [  bestOptionID  -  1]  := 

stageOptions [  numberOf Stages ,  bestOptionID  ] .CUM_EFF; 

ChartFXl . CloseData (  COD_VALUES) ; 

//  Determine  Best  Predecessor  of  Final  Stage  Best  Option: 
currentOption  :=  stageOptions [  numberOf Stages,  bestOptionID  ] .BST  PREDEC; 

ChartFXl . OpenDataEx (  COD_VALUES ,  COD_UNCHANGE ,  COD_UNCHANGE ) ; 
for  index2  :=  (numberOf Stages  -  1)  downto  1  do 
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begin 

//  Backtrack  one  level: 

currentOption  :=  stageOptions [  index2  +  1,  currentOption  ] .BST_PKEDEC; 
ChartFXl . ThisSerie  :=  (index2  -  1)  ; 
if  showAverage 

then  ChartFXl. Value [  currentOption  -  1]  := 

(stageOptions [  index2,  currentOption  ] . CUM_EFF) / index2 
else  ChartFXl .Value [  currentOption  -  1]  := 

stageOptions [  index2 ,  currentOption  ] . CUM_EFF ; 

end; 

ChartFXl . CloseData (  COD_VALUES) ; 
if  showAverage 

then  ChartFXl .Adm [CSA_MAX]  :=  1.0 

else  ChartFXl. Adm [CSA_MAX]  :=  maxReturn  +  1; 

ChartFXl . Invalidate ; 

ChartFXl. Visible  :=  True; 

end; 

procedure  TfrmCharts . FormCreate ( Sender :  TObject) ; 
begin 

ChartFXl . StyleEx  :=  CSE_LAND SCAPE ; 

ChartFXl . TypeEx  :=  ChartFXl . TypeEx  or  CTE_NOTITLESHADOW; 
end; 
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procedure  Tfr,Cherts.Bia3tnlclick(S.nder:  Tobject) 
begin 

self .close ; 
end; 

end. 
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Figure  A  -  23  Data  Module  Form 


UNIT  DATMOD1  CODE 


unit  datModl; 

interface 

uses 

Windows,  Messages,  SysUtils,  Classes,  Graphics,  Controls,  Forms,  Dialogs, 
UCommon,  UTzODbf,  UTzDbf; 

type 

TDataModulel  =  class (TDataModule) 
topOptions:  TTzDbf; 
topResul ts :  TTzDbf ; 
topProbSiz:  TTzDbf; 
topCapCosts :  TTzDbf; 
stageEffDef :  TTzDbf; 
capabilityLabels :  TTzDbf; 
private 

{  Private  declarations  } 
public 


{  Public  declarations  } 


DataModulel :  TDataModulel ; 


Unit  input 

The  input  unit  provides 
code  and  a  user-interface 
form  inputForm  for 
reviewing  and  editing  the 
database  tables  which 
correspond  to  user  input. 


Nuqiberof  Stages 
Option  List  4  : : :  • 


Number  Of  Options: 


Number  of  Capabilities 


,  ’  4 


TINIT  INPUT  CODE 


unit  input; 

interface 

uses 

l  a  Classes  Graphics,  Controls,  Forms,  Dialogs 
Windows,  Messages,  SysUtxls,  Classes,  , 

StdCtrls ,  Buttons,  Grids,  ExtCtrls,  Mask,  aTzGrids, 
aTzNav,  aTzMask,  aTzEdit,  aTzMemo, 

type 

TinputForm  =  class (TForm) 

BitBtnl :  TBitBtn; 

Labe 11 :  TLabel ; 

Label2 :  TLabel ; 

Label 3 :  TLabel ; 

Label4 :  TLabel ; 

TzNavigatorl :  TTzNavigator; 

TzGridl :  TTzGrid; 

TzEditl :  TTzEdit; 

TzEdit2 :  TTzEdit; 

TzNavigator2 :  TTzNavigator ; 

TzGrid2 :  TTzGrid; 
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TzEdit3:  TTzEdit; 
TzEdit3Caption :  TLabel ; 
TzMemol:  TTzMemo; 

Label5 :  TLabel; 

TzNavigator3 :  TTzNavigator ; 
TzGrid3 :  TTzGrid; 
TzNavigator4 :  TTzNavigator; 
rgDisplay:  TRadioGroup; 
Label 6:  TLabel; 


procedure  FormActivate (Sender :  TObject) ; 

prooedur,  FormCloso  (Sender,  TObjsct;  var  Action 
private 

{  Private  declarations  } 
public 

{  Public  declarations  } 


TCloseAction) ; 


end; 


var 

inputForm:  TinputForm; 


implementation 


uses  datModl; 
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{ $R  *  .DEM} 


procedure  TinputForm . FormActivate ( Sender.  TObje 

begin 

DataModulel . topProbSiz .Active  :=  true; 
DataModulel . topProbSiz . GoTop ; 

DataModulel. topCapCosts. Active  ;=  true; 
DataModulel . topCapCosts . GoTop ; 

DataModulel. stageEffDef. Active  :=  true; 
DataModulel . stageEffDef . GoTop; 

DataModulel. capabilityLabels . Active  :=  true; 
DataModulel . capabilityLabels . GoTop ; 


ptoMd«~  TinputForm . FormClose (Sender :  T0ijeot; 
begin 

DataModulel. topProbSiz. Active  :=  false; 

DataModulel. topCapCosts. Active  false, 

DataModulel. stageEffDef .Active  :=  false; 

DataModulel. capabilityLabels. Active  :=  false; 


end. 


Unit  main 


The  main  unit  and  its  user-interface  form 
mainForm  provide  the  screen  from  which  all 
other  actions  in  the  program  derive  from,  and 
return  to.  This  is  the  form  on  which  the 
TParser  (called  TParserl)  and  Crystal  Report 
(called  CRPE1)  components  are  placed. 


Figure  A  -  25  Main  Form 
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UNIT  MAIN  CODE 


unit  main; 

interface 

US6S 

Windows ,  Messages,  SysUtils,  classes,  Graphics,  Controls,  Forms,  Dialogs 
StdCtrls,  ExtCtrls ,  option,  ParserlO,  UCRPE32 ,  report,  SplshDlg, 

type 

TmainForm  =  class (TForm) 

Bevel 1 :  TBevel ; 
btnView :  TButton; 
btnAnalyze:  TButton; 
btnResults ;  TButton; 
btnReports:  TButton; 

Parserl:  TParser; 

Labell;  TLabel; 

Label2 :  TLabel ; 

Label3 :  TLabel ; 

Label4 :  TLabel ; 

OpenDialogl :  TOpenDialog ; 

Crpel :  TCrpe; 
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Label5 :  TLabel ; 

Lab  el 6 :  TLabel; 

Label7 :  TLabel ; 

procedure  btnViewClick (Sender:  TObject) ; 
procedure  btnAnalyzeClick (Sender:  TObject) ; 
procedure  btnResultsClick (Sender :  TObject) ; 

procedure  FormClose (Sender :  TObject;  var  Action:  TCloseAction) ; 
procedure  FormCreate (Sender :  TObject); 
procedure  btnReportsClick (Sender :  TObject) ; 
private 

{  Private  declarations  } 
public 

{  Public  declarations  } 
end; 

var 

mainForm :  TmainForm ; 

numberOf Stages,  numberOf Options :  integer; 

//  Note  that  the  stageOptions  size  MUST  be  matched  in  main. close  event 
//  cleanup  of  TOption  instances. 
stageOptions:  array[0..30,  1..1000]  of  TOption; 
connectDatabasesToggle :  boolean ; 

CapArray:  array [1 .. 1000]  of  string; 

FilesLocation,  AppLocation:  string; 
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implementation 


uses  input,  datModl,  math,  charts,  IO_Form; 

{ $R  *  .DEM} 

var 

minStageScore:  single; 

stageEffectiveness ,  sampleEf f ectiveness ,  currentBestEffectiveness:  single; 
numberOf Capabilities :  integer ; 

transitionCost:  array [1. .500,  1..10,  1..10]  of  integer; 
largeCostValue ,  cumulativeCost,  costlncrement:  Longint; 
feasiblePredecessorExists :  boolean; 

prevCapabilityLevel ,  currentCapabilityLevel :  array [1. .500]  of  integer; 

procedure  analyze; 
var 

index,  stagelndex,  optionlndex,  previousStageOptionlndex:  integer; 
expressionToEvaluate :  TStringList ; 
stringExpression:  string; 
begin 
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DataModulel . topProbSiz . Active  : =  true ; 

numberOf Stages  : =  DataModulel . topProbSiz . GetLongField ( ' num_stages ' ) ; 
DataModulel . topProbSiz . Active  : =  false ; 

//Calculate  dynamic  program 

DataModulel . stageEf fDef . Active  : =  true ; 

express ionToEvaluate  :=  TStringList. create; 
dataModulel . stageEf fDef . DisableControls ; 
dataModulel . stageEf fDef . GoTop ; 

dataModulel . stageEf fDef . GetMField(  'DEFINE_EFF' ,  expressionToEvaluate) ; 
dataModulel . stageEf fDef . EnableControls ; 

stringExpression  :=  expressionToEvaluate [0] ; 
if  expressionToEvaluate. count  >  1  then 

for  index  :=  1  to  (expressionToEvaluate . count  -  1)  do 
begin 

stringExpression  :=  stringExpression  +  expressionToEvaluate [index] ; 
end; 

mainForm.Label3. Caption  :=  IntToStr(  GetTickCount ()  ); 
mainForm. Parserl . Expression  :=  stringExpression; 
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mainForm.Label4 .Caption  :=  IntToStr(  GetTickCount ()  ); 
expressionToEvaluate . Free ; 


For  stagelndex  :=  1  to  numberOf Stages  do 
begin 

for  optionlndex  :=  1  to  1000  do 
if  stageOptions [  stagelndex,  optionlndex  3  O  then 

begin 

feasiblePredecessorExists  :=  false; 

(*  HARD-WIRED  PARAMETERS  FOR  COST  ANALYSIS  CASE: 

/ /********************************************* 

//  largeCostValue  is  set  at  10  units  per  stage: 

largeCostValue  :=  10  *  stagelndex; 
minStageScore  : =  8 ; 

//*********************************************  *) 

(*  HARD-WIRED  PARAMETERS  FOR  RELIABILITY  CASE:  *) 

/ /********************************************* 

//  largeCostValue  is  set  at  10  units  per  stage: 

largeCostValue  :=  10  *  stagelndex; 
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minStageScore  :=  0.5; 

//************************i,i,i'i,i,i,i'i'i,i,ili'i'iti'i'1'it1'it1' 

currentBestEffectiveness  :=  0; 


mainForm.Parserl. Variable!  'CAP1'  ] 

:=  stageOptions [  stagelndex,  optionlndex  ].CAP__1; 

mainForm.Parserl. Variable [  'CAP2 '  ] 

:=  stageOptions [  stagelndex,  optionlndex  ].CAP_2; 
mainForm.Parserl. Variable!  'CAP3 '  ] 

:=  stageOptions!  stagelndex,  optionlndex  ] .CAP__3; 
stageEf f ectiveness  : =  mainFonn . Parserl . Value ; 

StageOptions  I  stage*,**,  optionlndex  KSTASEJSFP  stageEftectiveness 
for  previousStageOptionlndex  :=  1  to  1000  do 

begin 

if  StageOptions!  stagelndex-!,  previousStageOptionlndex  )  o  nil  then 
rf  (  (stageEffectiveness  >  minStageScore) 

and  (stageOptions!  stagelndex-l ,  previousStageOptionmdex  , 
.Feasible  =  'Y') 

) 

then 

begin 

//Look  at  possible  transition  from  feasible  predecessor 
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//USE  largeCostValue  to  veed  out  infeasible  transition. 
sampleEffectiveness  := 

stageOptions  l  stagelndea-l,  previousStageOptionlndea  !  .OUM_E 

+  stagnations!  staged,  optionlndea 

if  (sampleEffectiveness  >  currentBestEffectlvenes  ) 

begin 

prevCapabilityLevel [ 1 ] 

stageOptions [  stagelndea-l ,  previousStageOptionlndea  1  •=»_ 
currentCapabili tyLevel [ 1 ] 

:=  stageOptions [  stagelndex,  optionlndex  ].CAP_1; 

prevCapabilityLevel 121 

i=  stageOptions!  stagelnd^-l,  previousStageOptionlndea  1  .<M_ 
currentCapabili tyLevel [2] 

.=  stageOptions [  stagelndex,  optionlndex  ]  .CAP_2; 

prevCapabilityLevel [3] 

...  StageOptions!  stagelndea-l ,  previousStageOptionlndea  ]  .CAP. 

currentCapabilityLevel [3] 

:=  stageOptions [  stagelndex,  optionlndex  ] .CAP — 3, 

costlncrement  := 

transitionCost [  1 , 

prevCapabilityLevel  Ill ,  currentCapabilityLevel  Ill  1 

+  transitionCost [  2, 

prevCapabilityLevel [2],  currentCapabilityLevel [2]  ] 

+  transitionCost!  3, 


prevCapabilityLevel [3] ,  currentCapabilityLevel [3]  ]; 
cumulativeCost  := 

stageOptions [  stagelndex-l,  previousStageOptionlndex  , .COM  CST 
+  costlncrement; 

if  (cumulativeCost  <  largeCostValue)  then 
begin 

currentBestEffectiveness  :=  sampleEffectiveness; 
feasiblePredecessorExists  :=  true; 
stageOptions [  stagelndex,  optionlndex  ] . CUM  EFF 

:=  currentBestEffectiveness; 

stageOptions (  stagelndex,  optionlndex  ]  .BST  CST  IN 
:=  costlncrement; 

stageOptions [  stagelndex,  optionlndex  ] .CUMCST 
:=  cumulativeCost; 

tageOptions(  stagelndex,  optionlndex  ]  .BST  PREDEC 

St*9‘°Pti0nS[  stageIndex-l i  PreviousStageOptionlndex  J. OPTION  m 
stageOptions [  stagelndex,  optionlndex  ] -FEASIBLE  :=  iyi; 
end; 

end; 

end; 

end; 

end; 

end; 
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itaModulel .  stageEffDef -Active  :=  false; 


ptooedur.  TmainForm.btnViewClick (Sender:  lObject) ; 

var 

capability Index,  index,  indexl,  index!:  integer,- 
locationSpecified:  boolean; 

begin 


if  ConnectDatabasesToggle  then 

begin 

locationSpecified  :=  false; 

trY  , , ,  ,  „at  a  f ile  location  for  the  scenario  to  analyze . ' )  ( 

ShowMes s age (  Select  a  ri 
while  not  locationSpecified  do 

begin 

if  OpenDialogl. Execute  then 


begin  . 

FilesLocation  ExtractFilePath (OpenDialogl  -Filename)  ; 

locationSpecified  :=  true; 

_^™.Caotion  :=  mainForm. caption  +  FilesLocation; 


mainForm . Caption 


DataModulel .  topOptions .  Dbf  FileName  :=  FilesLocation  *  '  \optrons .  DBF 


ataModulel . topProbSis .DbfFiletlane  FilesLocation  +  ,Vprob  sil.DBF, 
ataModulel  topResults  DbfFileName  FilesLccationi  1  \results . DBF '  • 

ataModulel.  topCapCosts.  DbfFileName  FilesLocation  a  .\cap  cost.DBF 

DataModulel  .stageEffDef  .DbfFileName  :=  FilesLocation  ♦  . Ndef’.ff . EBP . 
DataModulel  capabilityLabels . DbfFileName  FilesLocation  ♦  T\oap  lab! 
ConnectDatabasesToggle  :=  false; 
except 

ShowMessage ( 'Unsuccessful  at  using  input  file  location  •)  . 
end;  '  '  ' 


end; 


//  Reset  Feasibility  Values  on  Input  Table: 

DataModulel  topOptions .  disableControls ;  //Necessaty  to  enable  preper  loopin 
DataModulel .  topOptions  .Active  :  =  true; 

DataModulel . topOptions . GoTop; 

while  not  DataModulel. topOptions. dEOF  do 
begin 


DataModulel 

DataModulel 

DataModulel 

DataModulel 

DataModulel , 

DataModulel 


.  topOptions .  SetCField  ( '  FEASIBLE 
.  topOptions .  SetRealField  ( '  STAGE__EFF ' ,  (-1)  j  . 

topOptions. SetLongField('BST_PREDEC»,  (  -i) 
topOptions. SetLongField('BST_CST  IN' , (-1)  )• 

.  topOptions . SetRealField ( 'CUM_EFF ' , (-1)  ) ; 

.  topOptions . SetLongField ( ' CUM_CST ' , (-1)  ) ; 


DBF' ; 
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if  (DataModulel . topOptions . GetLongField ( ' STAGE  )  0  ) 

then 

begin 

DataModulel . topOptions . SetCField ( 'FEASIBLE' ,  'Y' )  / 
DataModulel . topOptions . SetRealField ( ' STAGE_EFF  ,  0  ), 

DataModulel .  topOptions .  setLongField<  'Bsr_PREDEC' ,  0  ).' 

DataModulel .  topOptions .  SetLongField ( ' BST_CSI_IN ' ,  0)  , 
DataModulel .  topOptions .  SetRealField ( '  CUM_EFF  ,  0), 

DataModulel.  topOpUons. SetLongField ('COM.OST' ,  0)  , 

end 

else 

.  .  Gflfrvialdl 1  FEASIBLE 1  /  )  r 

DataModulel . topOptions . SetCFieia  V 

DataModulel . topOptions . Rlock ; 

DataModulel . topOptions . Replace ; 

DataModulel . topOptions . unLock ; 

DataModulel . topOptions . skip (D ! 

mainForm . Invalidate ; 


end; 

DataModulel . topOptions . enableControls ; 
DataModulel . topOptions . GoTop ; 


//Necessary  to  enable  proper  looping 


DataModulel. topCapCosts. Active  true 

DataModulel . topCapCosts . GoTop ; 
inputForm . showModal ; 


DataModulel . topProbSiz . Active  :=  true; 

nunberOf Capabilities  :«  DataMaduld. topPr<.bSii.G.tLo„gFie1d(.„„»  cap',  • 
DataModulel. topProbSiz. Active  :=  false; 

//  Read  cost  values  into  transitionCost  matrix: 

DataModulel . topCapCosts .Active  :=  true; 

DataModulel . topCapCosts . GoTop; 

//  Initialize  cost  matrix  to  zeroes: 

for  capability Index  :=  1  to  numberOfCapabilities  do 

for  indexl  :=  1  to  10  do  yy 

' /  array  dimensions  should 
for  index2  :=  1  to  10  do  /y 

//  correspond  to  array  declaration!!? 

transitionCost [  capability Index,  indexl,  index2  ]  :=  0; 

//  Read  in  database  cost  values: 

while  not  DataModulel. topCapCosts. dEOF  do 
begin 

capability Index  :=  0; 

if  trim (DataModulel. topCapCosts. GetCPield( -CAPABILITY ', )  =  -CAP  1- 
then  capability Index  :=  1 
else 

if  trim (DataModulel. topCapCosts. GetCField (- CAPABILITY •) )  =  -CAP  2- 
then  capabilitylndex  :=  2 
else 

if  trim (DataModulel. topCapCosts. GetCField( -CAPABILITY' ) )  =  -CAP 
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then  capabilitylndex  :  3 

else  showMessage  ( ' Capability  xdenfication  error:  • 

*  DataMbdulel .  topCapCosts .  GetCField  ( '  CAPABILITY ')  +  '!'  )  , 

indexl  :=  DataModulet .  topCapCosts . GetlongField ( ' FR0M_1SVEX. ■ )  / 

index2  I »  DataModulel .  topCapCosts ,  GetLongField  ( ’  TO_LEVEL  ), 
transitionCoatt  oapabilitylndex ,  indexl,  index2  1  DataModulel . 

topCapCosts . GetLongField ( ' COST ' ) ; 

DataModulel . topCapCosts . Skip  <D ! 
end; 

//Setup  variables  for  use  internally  in  TParser 
if  numberOf Capabilities  >  sizeOf (  CapArray  >  then 

ShowMessage (-Too  many  capabilities  specified.'); 
for  index  :=  1  to  numberOf Capabilities  do 

begin 

„  .  .  i  iran'  +  IntToStr (  index  ) ; 

CapArray  [  index  ]  Cap  + 

//Initialize  variables  in  Parser,  set  value  to  index 
Parserl. Variable [  capArray [index]  ]  :=  index; 

end; 


//  Allow  Analysis  to  Proceed 
btnAnalyze . enabled  :=  true; 


end; 


procedure  TmainForm . btnAnalyzeClick (Sender :  TObject)  ; 
var 

stagelndex,  optionlndex:  integer; 
tempOption:  TOption; 
begin 

//Move  options  information  to  array  of  option  objects  (For  Execution  Speed 
//  when  performing  analysis. 

DataModulel . topOptions . Active  : =  true ; 

DataModulel . topOptions . GoTop ; 

DataModulel . topOptions . disableControls ; 
while  (not  DataModulel . topOptions . dEOF)  do 
begin 

stagelndex  : =  DataModulel . topOptions . GetLongField ( ' STAGE ' ) ; 
optionlndex  : =  DataModulel . topOptions . GetLongField ( ' OPTION_NUM ' ) ; 

//if  stageOptions [  ,  ]  is  not  nil,  FREE  before  using, 
if  (stageOptions [  stagelndex,  optionlndex  J  <>  nil) 
then  stageOptions I  stagelndex,  optionlndex  ].Free; 
stageOptions [  stagelndex,  optionlndex  ]  :=  TOption . Create ; 
stageOptions [  stagelndex,  optionlndex  ] . readFromOptionArray; 

DataModulel . topOptions . skip (1) ; 
end; 

DataModulel . topOptions . enableControls ; 
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analyze; 


try 

DataModulel . topResults . Active  : =  true ; 

DataModulel . topResul ts . disableControls ; 

DataModulel . topResults . GoTop; 

while  not  DataModulel . topResults . dEOF  do 

begin 

//Lock  record  to  delete 
DataModulel . topResults . RLock ; 

DataModulel . topResults . DeleteRec ; 

DataModulel . topResults . UnLock ; 

DataModulel . topResults . Skip (1) ; 
end; 

DataModulel . topResults . pack ; 

DataModulel . topResults . enableControls ; 
except 

//Do  nothing 
end; 

DataModulel . topResults . disableControls ; 
if  (DataModulel. topResul ts.RecCount  >  0) 

then  ShowMessage( 'Results  Table  not  cleared  correctly'); 
For  stagelndex  :=  1  to  numberOf Stages  do 
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for  optionlndex  :=  1  to  1000  do 
begin 


//  If  stageOptions [  stagelndex,  optionlndex  ]  <>  nil  then 
//  copy  the  option  to  the  results  table! 

if  stageOptions [  stagelndex,  optionlndex  ]  <>  nil  then 
begin 

tempOption  :=  stageOptions [  stagelndex,  optionlndex  ]; 

//  APPEND  chronology  is  important  to  sequence  right!! 

//  CLEAR  the  record  buffer,  input  new  record,  THEN  append. 

DataModulel . topResults . clearRecord; 

DataModulel .  topResults .  SetlongFiald  ( '  STAGE ' ,  tempOption  .STAGE) ; 
DataModulel .  topResults .  SetLongPield  <  •  OPTION®*,  . ,  tempOption .  OPTIONJTOM) 
DataModulel .  topReaults .  SetLongPield,  'CAP_1 ' ,  tempOption. CAP_1)  ; 
DataModulel .  topResults .  SetLongPield  ( '  CAP_2  ■ ,  tempOption .  CAP_2>  , 
DataModulel .  topResults .  SetLongPield  ( •  CAP_3  ■ ,  tempOption .  CAP_3) , 
DataModulel .  topResults .  SetCPield <• FEASIBLE ■ ,  tempOption . FEASIBLE)  ; 
DataModulel .  topResults .  S.tRealPield  ( ■  STAGE_EPP* ,  tempOption .  STAGE_EFF)  ; 

DataModulel.  topResults. SetLo„gFi.ld(.BST_PREDEC',t.mpOption.BST_PREDEC) 

DataModulel .  topResults .  SetLongPield ( 'BST_CST_IN ' , tempOption . BST_CST  IN) 

DataModulel. topResults. SetRealField('CDM_EPp.,te«T,Option.cUM_EFF)  . 

DataModulel .  topResults .  SetLongPield  ( '  CIMCST  ■ ,  tempOption .  CTMCST)  ; 

/ /  FILE  MUST  BE  LOCKED  TO  APPEND 
DataModulel . topResults . ALock ; 

DataModulel . topResults .Append; 


A -59 


DataModulel . topResul ts . unLock ; 


end; 


end; 

DataModulel . topResul ts . enableControls ; 
btnResults .Enabled  :=  true; 
btnReports . Enabled  ; —  true ; 

DataModulel. topResults. Active  :=  False; 

end; 


procedure  TmainForm.btnResultsClick (Sender :  ^Object) 

begin 

//  Intended  to  generalize  later! 
numberOf Options  :=  27; 
f rmCharts . Show ; 
end; 


procedure  TmainForm . FormClose (Sender:  TObject;  var  Action 
var 

indexl,  index2 :  integer; 
begin 

DataModulel . topOptions . close ; 

DataModulel . topResults . close ; 

DataModulel . topProbSiz . close ; 


TCloseAction) 


DataModulel . topCapCosts . close ; 


DataModulel . capabilityLabels . close; 
for  indexl  :=  0  to  30  do 

for  index2  :=  1  to  1000  do 

if  (stageOptions [  indexl,  index2  ]  <>  nil) 

then  stageOptions [  indexl,  index2  ].Free; 


end; 


procedure  TmainForm. FormCreate (Sender :  TObject); 
begin 

ConnectDatabasesToggle  :=  true; 

Application  :=  ExtractFilePath (Application. ExeName) ; 
end; 


procedure  TmainForm. btnReportsClick (Sender :  TObject); 
begin 

f rmReport . ShowModal ; 
end; 


end. 
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UNIT  OPTION  CODE 


unit  option; 


{$M+}  {Allow  published  vars  -  generate  RTTI  information) 


interface 


uses 

SysUtils ; 

type 

TOption  =  class (TObject) 
public 

STAGE :  integer ; 

OPT ION_NUM :  integer ; 
CAP  1 :  integer ; 

CAP  2 :  integer ; 

CAP  3 :  integer ; 
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FEASIBLE:  string; 

STAGE_EFF:  single; 

BST_PREDEC:  integer; 
BST_CST_IN:  longlnt; 

CUM_EFF:  single; 

CUM_CST :  longlnt ; 
constructor  Create; 
procedure  readFromOptionArray; 
procedure  saveToResultArray; 
published 

end; 


implementation 

uses 

main,  datModl; 

constructor  TOption . Create ; 
begin 

inherited  Create; 

STAGE  :=  -1; 


OPT ION_NUM  :=  -1; 

CAP _ 1  :=  -1; 

CAP _ 2  :=  -1; 

CAP _ 3  :=  -1; 

FEASIBLE  := 
STAGE_EFF  :=  -1 ! 
BST_PREDEC  :=  -l; 
BST_CST_IN  :=  -1; 
CUM_EFF  :=  -1; 
CUM__CST  :=  -1; 

end; 


procedure  TOption . readFromOptionArray ; 
begin 


STAGE  : =  DataModulel . topOptions . GetLongField ( ' STAGE ' ) ; 

OPTION_NUM  : =  DataModulel . topOptions . GetLongField { ' OPTION_NUM ' ) ; 
CAP  1  :  =  DataModulel .  topOptions .  GetLongField  ( '  CAP — 1 ' )  ; 

CAP  2  :  =  DataModulel .  topOptions .  GetLongField  ( '  CAP — 2 ' )  , 

CAP  3  : =  DataModulel . topOptions . GetLongField ( ' CAP — 3 ' ) ; 

FEASIBLE  :=  DataModulel. topOptions. GetCFieldC FEASIBLE  ), 

STAGE_EFF  : =  DataModulel . topOptions . GetRealField { ' STAGE_EFF ' )  ; 
BST_PREDEC  : =  DataModulel . topOptions . GetLongField ( ' BST_PREDEC ' ) ; 
BST_CST_IN  : =  DataModulel . topOptions . GetLongField ( ' BST_CST_IN ' )  ; 
CUM  EFF  :=  DataModulel . topOptions . GetRealField ('CUM_EFF'); 
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CUM_CST  : =  DataModulel . topOptions . GetLongField ( ' 


CUM  CST ' 


end; 

procedure  TOption. saveToResultArray; 

begin 

end; 

end. 
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the  application  to  provide  interactive  reporting  facilities. 


m  Report  Options 


: ;  report  iiinaa ; ; ;  ?;  I;;-?. 

>  .  i  i‘  .  •  fj  *  *  "1 


Figure  A  -  26  Report  Form 


UNIT  REPORT  COFtF 


unit  report; 

interface 

uses 

Windows ,  Massages,  SysUtils,  Classes,  Graphics,  Controls,  Foras,  Dialogs 
Buttons,  StdCtrls,  ExtCtrls; 

type 

TfrmReport  =  class (TForm) 

RadioGroupl :  TRadioGroup; 

Buttonl :  TButton; 

BitBtnl :  TBitBtn; 

procedure  ButtonlClick (Sender:  TObject) ; 
procedure  FormActivate (Sender :  TObject); 
private 

{  Private  declarations  } 
public 

{  Public  declarations  } 
end; 

var 
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frmReport:  TfrmReport; 
reportSubTitle :  string , 

implementation 

uses  main ; 


{ $R  *  .DEM} 


procedure  TfrmReport . ButtonlClick (Sender:  TObject) ; 
var 

reportNumber :  integer ; 

reportFile,  reportTitle,  windowTitle:  string; 
index :  integer ; 
begin 

//'Application'  already  set  as:  ExtractfilePath (Application. EreN»»e)  , 
reportNumber  :=  RadioGroupl . itemlndex  +  1; 
if  reportNumber  =  1  then 
begin 

reportTitle  :=  'Cost  Report:  '+  reportSubTitle; 

reportFile  :=  Application  +  'Cost.rpt'; 
windowTitle  :=  'COST  Report’; 
end; 

if  reportNumber  =  2  then  begin 


reportTitle  :=  'Option  Report:  '+  reportSubTitle; 
reportFile  :=  AppLocation  +  ' Options. rpt' ; 

windowTitle  :=  'OPTIONS  Description  Report'; 
end; 

if  reportNumber  =  3  then 
begin 

reportTitle  :=  'Results  Report:  '+  reportSubTitle; 
reportFile  :=  AppLocation  +  ' Results . rpt ' ; 
windowTitle  :=  'Overall  Results  Report'; 
end; 

//  Set  the  report  DataFilesLocation  to  the  database  FilesLocation. 
mainForm. CRPEi . DataFilesLoeation  :=  FilesLocation; 

mainForm . CRPE1 . ReportName  :=  reportFile; 
mainForm. CRPEI. ReportTitle  :=  reportTitle; 
mainForm . CRPEI .WindowTitle  : =  windowTitle ; 
mainForm . CRPEI . Execute ; 
end; 

procedure  Tf rmReport . FormActivate (Sender:  TObject) ; 
var 

description:  string; 
begin 
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if  reportSubTitle  =  ' ' 

then  description  :=  'A  Scenario' 
else  description  :=  reportSubTitle; 
reportSubTitle : =  InputBox ( ' Sub-Title ' , 

•Please  provide  a  short  report  description', 

end; 

end. 


description)  ; 


A -70 


Unit  spacing 

“SPaCe  "  3  SimP'e  ^  ““  C0MdtateS  ^  ^  «o  allow  ,he 


Figure  A  -  27  Spacing  Form 


UNIT  SPACING  CODE 

unit  spacing; 

interface 

uses 

Windows,  Messages,  SysUtils,  Classes,  Graphics,  Controls,  Forms,  Dialogs 
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ComCtrls,  StdCtrls,  Buttons; 

type 

TfrmSpace  =  class (TForm) 

TrackBarl:  TTrackBar; 

Label 1 :  TLabel ; 

Label2 :  TLabel ; 

Label3 :  TLabel ; 

Label4 :  TLabel ; 

Label5 :  TLabel ; 

BitBtnl :  TBitBtn; 

procedure  TrackBarlChange (Sender:  TObject) 
private 

(  Private  declarations  > 
public 

{  Public  declarations  } 
end; 

var 

f rmSpace :  TfrmSpace ; 
implementation 


uses  charts; 
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{$R  *  .DEM} 


procedure  TfrmSpace. TrackBarlChange {Sender:  TObject) ; 
begin 

f rmCharts . ChartFXl . f ixedGap  :=  5  *  TrackBarl. Position; 

Labell . Caption  :=  'Gap  is:  ' 

+  intToStr (f rmCharts . ChartFXl . f ixedGap) ; 
f rmCharts . invalidate; 
end; 

end. 
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Formulation  of  the  Sample  Problem 


The  sample  problem  can  be  formulated  under  the  following  headings: 


•  State  space, 

•  Optimal  value  function, 

•  Policy  reliability, 

•  Recurrence  relationship, 

•  Boundary  conditions, 

•  Statement  of  answer,  and 

•  Optimal  policy  function. 


State  Space 

At  each  stage,  there  are  twenty-seven  capability  vector  options  ranging  from  [1,1,1]  to 
[3,3,3]  as  described  in  the  main  paper. 

For  stage  i  and  capability  vector  j  where  1  <  j  <  27,  an  option  can  be  represented  as  : 

O  j=  [  X;jl,  Xij2,  Xjj3  ] 

where  xyi,  xp,  and  xy3  are  used  to  map  the  capability  vectors,  xyi  represents  the  Medical 
Support  capability  level,  xij2  represents  the  Lift  &  Position  capability  level,  and  xy3 
represents  the  C&C  (JFHQ)  capability  level.  In  the  sample  problem,  for  instance.  On  = 
[1.1,1]. 

This  state  space  is  restricted  in  this  problem  by  cost  constraints,  which  are  applied  in 
concert  with  the  Dynamic  Programming  recurrence  relationship,  to  ensure  that  any 
possible  solution  path  satisfies  the  following: 

(Total  Cost  through  Stage  i)  <  (i  *  10) 

The  state  space  is  further  restricted  with  an  objective  value  threshold  constraint  (see 
reliability  below.) 

Policy  Reliability 

The  choice  of  a  policy  (or  an  option)  Oy  gives  a  reliability  gy  where: 
gij  =  (0.999  -  ((3  -  xj,)  /  12))  *  (0.999  -  ((3  -  xij2  )  /  6)) 

*  (0.999  —  ((3  —  Xjj3  )  /12)) 
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A  reliability  threshold  is  applied  in  the  sample  problem.  Whenever  gy  <  0.5  the 
corresponding  option  is  considered  to  be  unsuitable,  and  is  not  considered  as  part  a 
potential  solution. 

Optimal  value  function 

The  optimal  value  function  can  be  described  as: 

fy  =  maximum  reliability  obtainable  by  combining  some  assignment  up  to  stage  i  -1 
with  the  option  Oy  in  stage  i,  subject  to  cost  constraints. 

For  results  presentation,  the  maximum  average  reliability  (  fj  /  i )  based  on  the  optimal 
value  function  is  shown. 

Recurrence  Relationship 

The  state  space  is  restricted  when  applying  the  recurrence  relationship  to  recording  only 
those  options  that  meet  both  the  cost  constraint  and  the  reliability  threshold. 

The  cost  of  going  from  Option  Oj.i,k  in  stage  i-1  to  Option  Oy  in  stage  i  is  defined  as: 
c(  Oi-i,k>  Oy  ) 

and  is  supplied  as  an  input  value. 

The  recurrence  relationship  used  to  define  the  optimal  overall  policy  assignment  is: 

£j  =  max  {  gy  +  fj_i;k  }  for  1  <  j  <  27  and  1  <  k  <  27 

subject  to 

c(fij)<  (i  *  10) 

and 

gij  <  0-5 

where  the  cost  of  fy  is  defined  as: 

c(  fjj  )  =  c(  Oj.i)k,  Oy  )  +  c(  fi.i,k  ) 

[HOW  IT’S  DONE  IN  THE  CODE:  When  examining  options  at  a  stage  i,  the  optimal 
intermediate  paths  for  all  feasible  options  through  stage  i-1  are  already  determined.  For 
each  option  j  in  stage  i,  each  feasible  option  in  stage  i-1  is  examined,  and  the  one  which  is 
both  feasible  (i.e.  it  can  be  reached,  the  cost  constraint  is  not  violated,  and  the  reliability 
threshold  is  met)  and  provides  the  maximum  reliability  is  chosen  for  fjj.  A  toggle  switch 
is  used  for  each  option  to  record  whether  it  is  feasible  or  not  as  the  algorithm  proceeds. 
Also,  the  best  predecessor  is  recorded  for  future  reference  as  fy  is  determined.  In  the 
sample  code,  only  one  predecessor  is  recorded.  A  possible  generalization  to  the  code  is, 
in  the  case  of  ties,  to  record  a  list  of  optimal  predecessor  options.] 
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Boundary  conditions 

Boundary  conditions  for  applying  the  recurrence  relationship  are: 
foi  =  0 
c(  foi  )  =  0 

The  starting  option  at  stage  0  is  Ooi  =  [1,1,1] 

Statement  of  Answer 

In  the  sample  problem  with  five  stages  modelled,  the  answer  is: 

f5*  =  max  fiy  for  1  <  j  <  27 

giving  fj*  as  the  optimal  value  of  the  objective  fimction. 


Optimal  Policy  Function 

Having  identified  fs*,  the  intermediate  policies  or  options  which  provide  the  answer  can 
be  identified  with  the  relationships: 

Optimal  policy  or  option  at  stage  5  is: 

Osj  where  j  is  the  option  associated  with  the  optimal  answer  fs*. 

Given  an  identified  optimal  policy  Oij  at  stage  i,  Oj.i^is  an  optimal  policy  if: 

c(  Om*  Oy  )  +  c(  fi_i;k  )  =  c(  f-j  ) 

and  Oi-i,k  is  a  feasible  option. 

Backtracking  from  the  stage  5  option  with  the  relationship  can  identify  intermediate 
policies  or  options 


[HOW  IT’S  DONE  IN  THE  CODE:  Once  the  answer  has  been  determined,  it  is 
straightforward  to  identify  the  optimal  option  at  the  final  stage,  and  to  backtrack  using 
recorded  predecessor  information  to  the  initial  option.  The  list  of  options  so  identified  is 
an  optimal  overall  policy,  given  the  assumptions,  input  data,  and  constraints  of  the 
sample  problem.  A  possible  generalization,  if  all  optimal  predecessors  were  recorded  in 
the  case  of  ties,  would  be  to  produce  either  all,  or  some  representative  subset,  policies 
which  are  optimal.  Another  possible  generalization  would  be  to  record  even  more 
detailed  information  along  the  way  so  that  a  number  of  the  “close  to  optimal”  policies 
could  also  be  generated  for  analysis  and  discussion  purposes.] 
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